This invention relates to the field of message delivery in messaging networks. In particular, the invention relates to message delivery of messages that can be uniquely identified by the consumer before being consumed.
An example of a message that can be uniquely identified before being consumed is a reply message in a request/reply system. Within a messaging network requesters send requests and receive replies, and responders receive requests and send replies.
A level of high availability may be achieved at the front end of the messaging network by providing a plurality of message managing systems to which requesters connect and using a workload balancing mechanism that routes requester connections to available message managing systems. The backend may also be made more available by providing a plurality of message managing systems to which responders can connect and using a workload balancing mechanism on the front end message managing systems that routes request messages to available backend message managing systems. Requests may continue to be processed even if a front or backend messaging manager system is unavailable.
The overall problem is the availability issue associated with the routing of replies when affinities exist. Replies are typically routed by a backend messaging manager system to a particular front end messaging manager system and not workload balanced. The front end messaging manager system used is that through which the corresponding request message was sent. This is because requesters typically send a request and remain connected to the same messaging manager system until they received the corresponding reply. There is an affinity created between the reply and the front end messaging manager system. This creates a problem for the availability of a reply at the front end because the completion of the requester's work (send request, receive reply) is dependent on the continued availability of the messaging manager system from which it sent the request. If the messaging manager system fails after the request is routed to the backend and before the reply is routed to the front end, then the reply is held at the backend until the front end messaging manager system becomes available.
A further problem exists if the requester disconnects or is disconnected from a front end messaging manager system after it sends a request, but before the reply is received. Requester connections are workload balanced. So when the requester re-connects (for the purpose of receiving the reply), its connection could be workload balanced to a different front end messaging manager system to which it was originally connected. This results in a situation where the reply is unavailable to the requester until it re-connects to the correct front end messaging manager system.
One known solution to this problem is to use separate connection logic for requesters depending on their state. Before sending a request, the connection is workload balanced and after sending a request, but before receiving the reply, the connection is not workload balanced, but made to the messaging manager system with which the requester has an affinity.